Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[For discussion] Add args from #392

Open
wants to merge 3 commits into
base: master
Choose a base branch
from

Conversation

PyExplorer
Copy link

No description provided.

@PyExplorer PyExplorer changed the title Add args from [For discussion] Add args from Feb 21, 2021
@@ -54,15 +61,17 @@
help='Amount of Scrapy Cloud units (-u number)')
@click.option('-t', '--tag',
help='Job tags (-t tag)', multiple=True)
def cli(spider, argument, set, environment, priority, units, tag):
@click.option('-f', '--args_from',
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For consistency I'd suggest to use a hyphen, it'll be converted to args_from automatically

Suggested change
@click.option('-f', '--args_from',
@click.option('-f', '--args-from',

@@ -34,6 +34,13 @@
Similarly, job-specific settings can be supplied through the -s option:

shub schedule myspider -s SETTING=VALUE -s LOG_LEVEL=DEBUG

Also, the spider can be run with all arguments are taken from another job with -f option:
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we extend the logic to optionally inherit job-level settings as well (with a different option ofc)? Could be done separately, here I'm more worried about consistent API, say we reserve -f/--args-from for arguments, and -s/--settings-from for settings. Wdyt?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this makes totally sense, thank you :). For settings we already have "-s", we can use "-g/--settings-from" for example.
Apart from the settings, there are also parameters that we can take from the "parent" job
--environment (-n, --env-from)
--priority
--units
--tag
Not sure about the priority, units, tag, but what do you think about the environment?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Tbh the short flag -g here -g/--settings-from looks a bit misleading 🤔 Also inheriting different parameters from different jobs (say get tags from job A, get settings from job B etc) doesn't look useful in real life, you'd usually inherit parameters from a single job.

My suggestion here would be

  • add a single key-value param specifiying a job which we should use as a base one, like -i/--inherit-from
  • add boolean flags for different parameters, like --inherit-args, --inherit-settings, --inherit-environment, --inherit-tags
  • inheriting priority/units doesn't seem to be useful, that's just one number, but I might be wrong there
  • using --inherit-from without specifiying what exactly to inherit should fail with a warning

Your thoughts?

Copy link
Author

@PyExplorer PyExplorer Feb 26, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Although the argument's names are a bit long (--inherit-environment) but clear and no problem to use this I hope. And the approach with --inherit argument looks good and quite agile.

About using --inherit-from without specifiying what exactly to inherit should fail with a warning - what do you think if instead of raising a warning it will inherit all parameters (args, settings, environment, tags, priority, units) at once? In most cases, we need exactly this behavior. Or just add a new argument like to --inherit-all (in addition to --inherit-args, etc).

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

instead of raising a warning it will inherit all parameters

Looks good to me, let's go this way 👍🏻

def add_args_from_job(client, base_args, args_from):
if not args_from:
return base_args
job_args = get_args_from_parent_job(client, args_from).copy()
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we use copy.deepcopy here instead?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants